Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

internal : redesign rust-analyzer::config #16639

Merged
merged 2 commits into from
Apr 16, 2024

Conversation

alibektas
Copy link
Member

@alibektas alibektas commented Feb 22, 2024

This PR aims to cover the infrastructural requirements for the rust-analyzer.toml ( #13529 ) issue. This means, that

  1. We no longer have a single config base. The once single ConfigData has been divided into 4 : A tree of .ratoml files, a set of configs coming from the client ( this is what was called before the CrateData except that now values do not default to anything when they are not defined) , a set of configs that will reflect what the contents of a ratoml file defined in user's config directory ( e.g ~/.config/rust-analyzer/.rust-analyzer.toml and finally a tree root that is populated by default values only.
  2. Configs have also been divided into 3 different blocks : global , local , client. The current status of a config may change until rust-analyzer.toml #13529 got merged.

Once again many thanks to @cormacrelf for doing all the serde work.

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 22, 2024
@alibektas alibektas force-pushed the 13529/config_restruct branch from 6db7040 to 9208256 Compare February 22, 2024 23:47
@alibektas
Copy link
Member Author

I do not think the remaining clippy errors make much sense in this case.

crates/rust-analyzer/src/handlers/request.rs Outdated Show resolved Hide resolved
crates/rust-analyzer/src/handlers/request.rs Outdated Show resolved Hide resolved
crates/rust-analyzer/src/config.rs Outdated Show resolved Hide resolved
crates/rust-analyzer/src/config.rs Outdated Show resolved Hide resolved
crates/base-db/Cargo.toml Outdated Show resolved Hide resolved
crates/rust-analyzer/src/config.rs Outdated Show resolved Hide resolved
crates/rust-analyzer/src/config.rs Outdated Show resolved Hide resolved
crates/rust-analyzer/src/config.rs Outdated Show resolved Hide resolved
/// some rust-analyzer.toml file or JSON blob. An empty rust-analyzer.toml corresponds to
/// all fields being None.
#[derive(Debug, Clone, Serialize, Default)]
struct ConfigInput {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a bit unfortunate that we store unrelated configs in certain layers (global layer containing client configs for example). Would be nice to split that out somehow

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two options come to mind:

We can declare non-root nodes as of type LocalConfigInput. The problem with this is that once the root node is deleted, one of these non-roots will become a root-node and needs to be upgraded to a ConfigInput for which the rest of the configs can either be fetched from vfs but this is not sth we'd want to have as this would mean that config::Configneeds to have a reference to vfs. The second option is that I somehow compress rest of the data and take the load off of memory and then load it when needed. But I have no idea how this is done.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would the root node be deletable? There is always one root node (if it doesn't exist as a file it should just be set to the default)

@Veykril
Copy link
Member

Veykril commented Feb 27, 2024

Haven't looked at the split between local global and client yet. Will do that later. Additionally, one thing for a follow up we should look at is whether we can discard the json ptr deserialization approach now that the config structure is fully typed.

@Veykril Veykril added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 27, 2024
@bors
Copy link
Contributor

bors commented Mar 2, 2024

☔ The latest upstream changes (presumably #16704) made this pull request unmergeable. Please resolve the merge conflicts.

@alibektas alibektas force-pushed the 13529/config_restruct branch from f94ef73 to fa7f873 Compare March 5, 2024 00:24
@bors
Copy link
Contributor

bors commented Mar 5, 2024

☔ The latest upstream changes (presumably #16752) made this pull request unmergeable. Please resolve the merge conflicts.

@alibektas alibektas force-pushed the 13529/config_restruct branch from fa7f873 to f582c5b Compare March 5, 2024 17:24
@alibektas alibektas force-pushed the 13529/config_restruct branch from f582c5b to df101f4 Compare March 5, 2024 20:13
@alibektas alibektas added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 6, 2024
@bors
Copy link
Contributor

bors commented Mar 11, 2024

☔ The latest upstream changes (presumably #16473) made this pull request unmergeable. Please resolve the merge conflicts.

@alibektas alibektas force-pushed the 13529/config_restruct branch from df101f4 to b313968 Compare March 12, 2024 02:36
@alibektas alibektas added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 12, 2024
@alibektas
Copy link
Member Author

I am not satisfied with what I have now, but I also need to move forward with actually implementing ratoml tree to see what I need and what I don't.

@@ -6,7 +6,7 @@
//! Of particular interest is the `feature_flags` hash map: while other fields
//! configure the server itself, feature flags are passed into analysis, and
//! tweak things like automatic insertion of `()` in completions.

#![allow(dead_code)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be removed ideally

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there are parts that actually belong to what is to be implemented, so I can't remove this just yet.

crates/rust-analyzer/src/config.rs Outdated Show resolved Hide resolved
@bors
Copy link
Contributor

bors commented Mar 19, 2024

☔ The latest upstream changes (presumably #16889) made this pull request unmergeable. Please resolve the merge conflicts.

@alibektas
Copy link
Member Author

For integration tests it is necessary to discuss what will belong to global/local/client. After that, this part can be actually be merged.

@alibektas alibektas force-pushed the 13529/config_restruct branch 2 times, most recently from 8a4a7b2 to 2059584 Compare March 22, 2024 00:37
@bors
Copy link
Contributor

bors commented Mar 25, 2024

☔ The latest upstream changes (presumably #16906) made this pull request unmergeable. Please resolve the merge conflicts.

alibektas and others added 2 commits April 15, 2024 14:14
This commit makes rust-analyzer::config module TOML ser and de.

Co-Authored-By: Cormac Relf <web@cormacrelf.net>
@Veykril Veykril force-pushed the 13529/config_restruct branch from 747addb to 60d3a73 Compare April 15, 2024 12:16
@Veykril
Copy link
Member

Veykril commented Apr 16, 2024

@bors r+

@bors
Copy link
Contributor

bors commented Apr 16, 2024

📌 Commit 60d3a73 has been approved by Veykril

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Apr 16, 2024

⌛ Testing commit 60d3a73 with merge 1179c3e...

@bors
Copy link
Contributor

bors commented Apr 16, 2024

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing 1179c3e to master...

@bors bors merged commit 1179c3e into rust-lang:master Apr 16, 2024
11 checks passed
bors added a commit that referenced this pull request Jun 6, 2024
feat: TOML based config for rust-analyzer

# TOML Based Config for RA

This PR ( fixes #13529 and this is a follow-up PR on #16639 ) makes rust-analyzer configurable by configuration files called `rust-analyzer.toml`. Files **must** be named `rust-analyzer.toml`. There is not a strict rule regarding where the files should be placed, but it is recommended to put them near a file that triggers server to start (i.e., `Cargo.{toml,lock}`, `rust-project.json`).

## Configuration Types

Previous configuration keys are now split into three different classes.

1. Client keys: These keys only make sense when set by the client (e.g., by setting them in `settings.json` in VSCode). They are but a small portion of this list. One such example is `rust_analyzer.files_watcher`, based on which either the client or the server will be responsible for watching for changes made to project files.
2. Global keys: These keys apply to the entire workspace and can only be set on the very top layers of the hierarchy. The next section gives instructions on which layers these are.
3. Local keys: Keys that can be changed for each crate if desired.

### How Am I Supposed To Know If A Config Is Gl/Loc/Cl ?

#17101

## Configuration Hierarchy

There are 5 levels in the configuration hierarchy. When a key is searched for, it is searched in a bottom-up depth-first fashion.

### Default Configuration

**Scope**: Global, Local, and Client

This is a hard-coded set of configurations. When a configuration key could not be found, then its default value applies.

### User configuration

**Scope**: Global, Local

If you want your configurations to apply to **every** project you have, you can do so by setting them in your `$CONFIG_DIR/rust-analyzer/rust-analyzer.toml` file, where `$CONFIG_DIR` is :

| Platform | Value                                 | Example                                  |
| ------- | ------------------------------------- | ---------------------------------------- |
| Linux   | `$XDG_CONFIG_HOME` or `$HOME`/.config | /home/alice/.config                      |
| macOS   | `$HOME`/Library/Application Support   | /Users/Alice/Library/Application Support |
| Windows | `{FOLDERID_RoamingAppData}`           | C:\Users\Alice\AppData\Roaming           |

### Client configuration

**Scope**: Global, Local, and Client

Previously, the only way to configure rust-analyzer was to configure it from the settings of the Client you are using. This level corresponds to that.

> With this PR, you don't need to port anything to benefit from new features. You can continue to use your old settings as they are.

### Workspace Root Configuration

**Scope**: Global, Local

Rust-analyzer already used the path of the workspace you opened in your Client. We used this information to create a configuration file that won't affect your other projects and define global level configurations at the same time.

### Local Configuration

**Scope**: Local

You can also configure rust-analyzer on a crate level. Although it is not an error to define global ( or client ) level keys in such files, they won't be taken into consideration by the server. Defined local keys will affect the crate in which they are defined and crate's descendants. Internally, a Rust project is split into what we call `SourceRoot`s. This, although with exceptions, is equal to splitting a project into crates.

> You may choose to have more than one `rust-analyzer.toml` files within a `SourceRoot`, but among them, the one closer to the project root will be
bors added a commit that referenced this pull request Jun 7, 2024
feat: TOML based config for rust-analyzer

> Important
>
> We don't promise _**any**_ stability with this feature yet, any configs exposed may be removed again, the grouping may change etc.

# TOML Based Config for RA

This PR ( addresses #13529 and this is a follow-up PR on #16639 ) makes rust-analyzer configurable by configuration files called `rust-analyzer.toml`. Files **must** be named `rust-analyzer.toml`. There is not a strict rule regarding where the files should be placed, but it is recommended to put them near a file that triggers server to start (i.e., `Cargo.{toml,lock}`, `rust-project.json`).

## Configuration Types

Previous configuration keys are now split into three different classes.

1. Client keys: These keys only make sense when set by the client (e.g., by setting them in `settings.json` in VSCode). They are but a small portion of this list. One such example is `rust_analyzer.files_watcher`, based on which either the client or the server will be responsible for watching for changes made to project files.
2. Global keys: These keys apply to the entire workspace and can only be set on the very top layers of the hierarchy. The next section gives instructions on which layers these are.
3. Local keys: Keys that can be changed for each crate if desired.

### How Am I Supposed To Know If A Config Is Gl/Loc/Cl ?

#17101

## Configuration Hierarchy

There are 5 levels in the configuration hierarchy. When a key is searched for, it is searched in a bottom-up depth-first fashion.

### Default Configuration

**Scope**: Global, Local, and Client

This is a hard-coded set of configurations. When a configuration key could not be found, then its default value applies.

### User configuration

**Scope**: Global, Local

If you want your configurations to apply to **every** project you have, you can do so by setting them in your `$CONFIG_DIR/rust-analyzer/rust-analyzer.toml` file, where `$CONFIG_DIR` is :

| Platform | Value                                 | Example                                  |
| ------- | ------------------------------------- | ---------------------------------------- |
| Linux   | `$XDG_CONFIG_HOME` or `$HOME`/.config | /home/alice/.config                      |
| macOS   | `$HOME`/Library/Application Support   | /Users/Alice/Library/Application Support |
| Windows | `{FOLDERID_RoamingAppData}`           | C:\Users\Alice\AppData\Roaming           |

### Client configuration

**Scope**: Global, Local, and Client

Previously, the only way to configure rust-analyzer was to configure it from the settings of the Client you are using. This level corresponds to that.

> With this PR, you don't need to port anything to benefit from new features. You can continue to use your old settings as they are.

### Workspace Root Configuration

**Scope**: Global, Local

Rust-analyzer already used the path of the workspace you opened in your Client. We used this information to create a configuration file that won't affect your other projects and define global level configurations at the same time.

### Local Configuration

**Scope**: Local

You can also configure rust-analyzer on a crate level. Although it is not an error to define global ( or client ) level keys in such files, they won't be taken into consideration by the server. Defined local keys will affect the crate in which they are defined and crate's descendants. Internally, a Rust project is split into what we call `SourceRoot`s. This, although with exceptions, is equal to splitting a project into crates.

> You may choose to have more than one `rust-analyzer.toml` files within a `SourceRoot`, but among them, the one closer to the project root will be
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants